Database management systems store extensive amounts of organized information for access by users of the systems. In a database system environment, the system responds to specific inquiries from the user as to which data to present from the database. Users can specify classes or types of data to retrieve from the database according to the conditions and criteria of their queries. Typically, users provide queries in a particular syntax of a particular database language that is used by the system, such as Structured Query Language (SQL) format.
The data in a relational database is typically organized in multiple tables or data files, and a logical group of these tables or files are stored in a logical storage unit or logical group of data, referred to herein as a “table space.” Each table space stores a subset of the database data and, all together, make up an entire database. In some databases, each table space might be organized to store tables of data that share a common characteristic, classification, or type, while in other databases, table spaces can each store different and varied types of data or data for a variety of uses. For example, one use of table spaces is to have each table space store only the data for one particular user of the database management system.
Database backups are typically performed periodically and routinely to create one or more copies of the database that store its data in safe, secondary storage areas, thus protecting the data of the database from unexpected data loss and errors. If data loss occurs in the active database, the data from a backup can be restored to reconstruct and recover the lost data. A set of backed up data is often referred to as a data “image.”
A backup image can include the data from an entire database, or just include the data from one or more individual table spaces of the database. Backups are typically performed at specific times throughout the history of a database, and are typically performed at either database granularity (backup up the entire database) or table space granularity (backing up individual table spaces within the database). Furthermore, some backups are full backups that store all the data in the specified database or table space, while other backups are “incremental” backups that store only some of the data, e.g., only changes made since a previous backup.
One problem in the prior database management systems is that a user cannot build (restore or create) an entire database from a set of table space backup images, i.e., without ever having backed up a full database backup image. There are no existing tools or infrastructure to restore and synchronize multiple individual table space images into an entire database. One reason for this inability to restore the full database is that two different table space backup images are typically backed up at different times, and there is no existing way to restore the individual table spaces to a consistent point in time. For efficiency, many data backups are performed at a table space level, so that this can be a serious limitation; it requires that the system administrator perform full database backups if they wish to restore the entire database at a future date.
Furthermore, it is not possible with existing systems to build a database-level database by restoring only a subset of the database, made up of table spaces. The administrator is required to restore or create the entire database, including all the table spaces, even if the administrator wishes only to restore a subset of the database, such as individual table spaces.
Accordingly, what is needed is the ability to build an entire database from a subset of the database, such as table spaces, as well as the ability to build only a subset of data from a database. The present invention addresses such a need.